more discussion points:

• Element stored Nodes as vector<Node*> vs vector<reference_wrapper<Node>>. Using them is kinda nasty both times:

// reference_wrapper<Node>
for (auto node_it=element.NodesBegin(); node_it!=element.NodesEnd(); ++node_it) {
    node_it->get().Id();
}

// Node*
for (auto node_it=element.NodesBegin(); node_it!=element.NodesEnd(); ++node_it) {
    (*node_it)->Id();
}

=> maybe we can have our own iterator that dereferences things right away?

• Do we need the Connectivities / NodeIds function for Element? => might only become clearer when using it => no for now, we add it if we need it :)
• Having a Nodes function like ModelPart has it will require to expose the container right? (would still be covenient though :)) => Won't we anyway needs sth like this for C and Python? => like in the link above we could provide an aux vector containing reference => although this is a performance overhead :/ => iterators is enough for now! (pybind works nicely with iterators)

@pooyan-dadvand I think this is ready. I would merge as is such that I can make the C and the Python interface. Once those are done then we are sure the basic capabilities work across languages and we can refine it / start using it

for future PRs:

• switch from shared_ptr to intrusive_ptr (as discussed)
• use an unordered_map as additional data-structure to speed up the Id-based search

@philbucher I think you are missing the element type in the element and also in the CreateNewElement interface

Let me go and prepare myself another coffee! Seems that I need it!

I just got confused between IdType and I_Type